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Cleanroom  Engineering  Project  Execution 
Section  1:  Introduction 

The  purpose  of  this  handbook  is  to  provide  managers  and  team  leaders  with  guidance  in  the 
planning,  directing  and  controlling  of  Cleanroom  projects.  This  class  of  decisions  are  called 
Project  Execution  decisions.  In  volume  2,  Project  Execution  was  defined  as: 

Project  Execution  is  the  planning  for,  direction  of,  and  controlling  of  the  solution  to  the  four 
major  decisions  within  a  software  project  These  decisions  are: 

1)  To  assign  tasks  to  specific  team  members  in  the  execution  of  the  project 

2)  To  determine  the  expected  completion  date  for  some  phase  of  a  project 

3)  To  determine  if  the  progress  made  toward  developing  the  desired  software  and  the 
resources  consumed  to  date  are  in  balance  with  each  other  and  with  the  project’s  Business 
Plan. 

4)  To  determine  if  some  aspect  of  the  design  is  acceptable  and  the  design  effort  should 
continue  in  the  current  direction  or  if  the  direction  should  be  altered.  If  the  direction  is 
to  be  altered  then  a  replanning  effort  must  be  initiated. 

Project  execution  decisions  are  made  by  team  leaders  and  the  software  engineering  manager  for 
a  specified  project  in  the  case  of  the  first  three  decisions.  In  the  case  of  last  decision  higher 
levels  of  management  may  be  involved  depending  on  the  financial  stakes  associated  with  the 
decision. 

1.1  Project  Execution  Decisions 

There  are  four  main  classes  of  decisions  that  team  leaders  and  the  software  engineering  manager 
need  to  make  while  executing  a  project  Each  of  these  classes  are  briefly  described  in  this 
section. 

1.  To  assign  tasks  to  specific  team  members  in  the  execution  of  the  project. 

This  decision  is  made  over  and  over  again  as  the  project  progresses.  This  decision  is  the 
dispatching  decision.  The  dispatching  decision  requires  current  knowledge  of  the  project  status 
and  resource  availability.  Dispatching  decisions  directly  impact  realization  loss.  The  term 
realization  loss  is  applied  to  the  concept  that  effort  is  wasted  when  ever  a  person  works  on  a  task 
or  attempts  to  work  on  a  task  and  subsequently  determines  that  some  part  of  the  prerequisite 
input  information  was  not  yet  complete,  correct  or  a  the  wrong  version  was  accessed.  Therefore, 
when  making  the  dispatching  decision  it  is  very  important  to  not  release  work  the  work  until  all 
inputs  are  available.  Every  time  a  task  is  released  for  execution  and  all  prerequisite  work  is  not 
complete  and  verified  as  correct  then  the  work  will  result  in  wasted  effort  or  realization  loss. 
In  typical  engineering  environments  realization  loss  is  a  major  source  of  reduced  productivity. 
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Typically,  no  planning  document  is  prepared  to  justify  a  dispatching  decision.  Dispatching 
decisions  are  normally  made  verbally  or  with  a  memo  or  there  may  be  an  assignment  form 
issued.  The  team  leader  may  prepare  a  line  and  page  schedule  (Gantt  Chart)  for  the  tasks  of 
immediate  concern  in  order  to  support  dispatching  decisions.  This  schedule  is  not  published. 
It  is  prepared  to  help  reach  a  personal  decision. 

In  Cleanroom,  when  using  CEPA  to  support  dispatching,  the  resource  assignment  is  made  by  the 
team  leader  by  filling  in  a  screen  and  the  dispatching  decision  is  automatically  made  when  all 
preconditions  are  fulfilled  according  to  the  Cleanroom  process  definition.  When  this  happens, 
the  task  is  put  on  the  engineers  pick  list  In  a  manual  situation,  the  same  process  must  be 
implemented  with  a  manual  procedure. 

Dispatching  in  the  Cleanroom  environment  is  discussed  in  section  2. 

2.  To  determine  the  expected  completion  date  for  some  phase  of  a  project. 

This  decision  is  to  support  a  control  decision.  As  projects  unfold,  the  progress  may  be  slower 
or  faster  than  anticipated.  Therefore,  at  frequent  intervals,  managers  are  required  to  re-estimate 
the  expected  completion  date  for  major  project  milestones.  Such  re-estimates  either  trigger  the 
need  for  a  replanning  effort  or  they  confirm  the  current  schedule. 

Typically  estimates  of  completion  dates  for  milestones  are  contained  in  a  status  report  or  some 
other  review  document 

Normally,  a  manager  will  need  to  prepare  a  model  to  determine  estimated  completion  dates.  In 
some  cases,  the  manager  or  team  leader  will  want  to  develop  a  Gantt  chart  or  network  model. 
This  can  be  done  using  any  of  the  standard  Project  Management  packages.  All  such  packages 
permit  the  model  to  be  displayed  in  either  form  and  many  permit  the  model  to  be  entered  in 
either  form.  The  important  issue  is  that  the  model  must  not  be  so  detailed  as  to  lose  perspective 
or  so  gross  as  to  have  no  meaning.  When  preparing  any  model  to  estimate  time  the  naming 
conventions  used  in  the  project  process  model  defined  in  the  Software  Development  Plan  (SDP) 
should  be  used  to  construct  the  model.  It  is  necessary  that  there  be  complete  traceability. 

In  making  forward  projections,  it  is  important  that  the  variability  that  can  occur  in  the  project  be 
included  in  the  model.  Traditional  methods  do  not  do  this.  As  discussed  above  in  point  1, 
models  of  software  development  projects  should  not  assume  a  waterfall  model.  An  accurate 
process  model  of  software  development  has  quite  a  complex  control  structure  and  any  particular 
project  can  take  quite  complex  paths  through  the  control  structure.  Therefore,  a  model  that 
permits  management  to  evaluate  the  expected  duration  and  variance  should  be  used.  Today, 
among  software  projects,  it  is  the  exception  to  use  such  models. 

Developing  estimates  of  project  completion  are  discussed  in  Section  4  of  volume  2. 
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3.  To  determine  if  the  progress  made  toward  developing  the  desired  software  and  the  resources 
consumed  to  date  are  in  balance  with  each  other  and  with  the  project’s  Business  Plan. 

The  basic  task  to  making  this  decision  is  to  make  the  right  measurements.  The  purpose  of  these 
measurements  is  to  support  a  replanning  decision  based  on  project  performance.  These  same 
measurements  support  the  dispatching  decision. 

The  actual  work  effort  performed  by  each  engineer  on  each  task  needs  to  be  collected.  CEPA 
can  be  developed  to  routinely  collect  all  the  required  measures. 

There  are  two  basic  types  of  measures.  Effort  measures  are  where  time  spent  by  engineer 
working  on  a  task  is  collected.  Progress  measures  are  where  the  material  contained  in  the  state 
data  repository  is  analyzed  to  determine  how  many  of  various  documents  are  complete  and  the 
extent  of  the  design  hierarchy  is  compared  to  current  projected  size  of  the  design  hierarchy. 

A  formal  planning  document  is  not  normally  prepared  to  support  the  decision  that  replanning  is 
required.  Managers  look  at  the  measurements  as  they  are  summarized  as  the  project  progresses 
and  they  make  a  judgement  to  initiate  a  replanning  effort  based  on  their  accumulated  wisdom. 

Metrics  collection  is  discussed  in  section  3  of  this  handbook. 

4.  To  determine  if  some  aspect  of  the  design  is  acceptable  and  the  design  effort  should  continue 
in  the  current  direction  or  if  the  direction  should  be  altered.  If  the  direction  is  to  be  altered  then 
a  replanning  effort  must  be  initiated. 

In  making  these  decisions,  the  manager  is  called  upon  to  use  his/her  engineering  judgment  to 
make  what  are  typically  very  difficult  decisions  that  have  a  great  influence  on  the  successful 
outcome  of  a  project  and  its  eventual  cost.  In  all  cases,  there  is  some  difficulty  with  the  current 
state  of  the  design.  When  such  suspensions  arise  there  are  two  basic  courses  of  action.  One  is 
to  continue  on  the  current  course  and  see  if  the  everything  in  fact  works  out  acceptably.  If  it 
does,  that  is  the  right  decision  because  the  desired  result  was  obtained  at  the  lowest  cost.  On  the 
other  hand,  if  at  some  later  stage  the  situation  becomes  impossible,  the  cost  of  rework  is  greater, 
or  it  may  even  be  so  high  that  it  becomes  necessary  to  scrap  the  project.  In  this  case,  the  wrong 
decision  was  made.  It  is  also  possible  that  a  project  can  be  stopped  to  consider  the  need  for 
rework  and  none  is  required.  In  that  case,  another  bad  decision  was  made.  Frequently,  these 
decisions  are  very  close  decisions  so  they  are  quite  difficult  to  make.  Typically,  it  takes 
experience  to  build  up  a  base  on  which  to  make  such  decisions. 

In  the  generic  process  model  presented  in  volume  1,  there  were  four  processes  defined  where 
such  decisions  need  to  be  considered.  The  four  processes  are: 
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proc  P4.L1:  Prepare  Plan  for  Cycle  i 
do  [P4.i.l:  Prepare  Plan  for  Cycle  i] 
con 

M4.L1.1:  Establish  Objectives  For  Cycle  i; 

M4.L1.2:  Allocate  Time  Period  To  Cycle  i; 

M4.i.l.3:  Prepare  Plan  For  Cycle  i; 

noc; 

until 

Completion  Conditions  achieved  for  M4.L1.1,  M4.i.l.2  and  M4.i.l.3 

od; 

corp; 

and 

proc  P4.i.5:  Appraise  Cycle  i  Specifications 

do  [P4.i.5:  Appraise  Cycle  i  Specifications] 

M4.L5.1:  Review  and  Evaluate  Cycle  i  specifications; 

M4.L5.2:  Management  Decision:  (1)  Specifications  Suitable  To  Initiate  Development  or 
(2)  Specification  Problems-Replan  Project  or  (3)  Continue  Specification  Effort 
with  cycle  i+1; 

until 

Completion  Conditions  achieved  for  M4.L5.2 

od; 

corp; 

The  following  two  tasks  have  to  with  providing  intellectual  leadership  through  the  provision  of 
engineering  judgement  in  two  critical  areas. 
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proc  PCS2:  Update  Specifications 

[This  process  results  in  an  updated  specification] 
do  [PCS2:  Update  Specification] 

if  Question  or  Issue  or  stimulus  from  outside  project  or  error  discovery  causes  a 
specification  change 

then 

do 

con 

SCS2.1:  Increase  Understanding  of  Problem  and  Solution  Domains; 

SCS2.2:  Update  Specification; 
noc; 

SCS2.3:  Publish  Change  Sheets; 

MCS2.4:  Management  Decision:  (1)  OK  continue  current  plan  with  revised 
specifications  or  (2)  Revised  specifications  require  replanning 

until 

Completion  Conditions  for  MCS2.4  achieved 

od; 

fi; 

od; 

corp; 

In  the  above  process,  the  situation  is  that  for  some  reason  the  previously  thought  to  be  complete 
specifications  have  to  be  changed.  The  question  is:  Can  the  teams  continue  under  the  current 
plan  or  is  it  best  to  initiate  a  replanning  activity  to  evaluate  the  economic  impact  of  the  change? 

In  the  following  process,  the  situation  is  that  during  the  certification  process  for  an  accumulation 
it  has  been  found  that  the  software  is  not  up  to  standard.  The  question  is  what  is  the  best  action 
to  take:  Continue  testing  and  fixing  or  reject  the  increment(s)  and  restart  design.  In  either  case 
is  it  necessary  to  start  a  replanning  activity  since  the  project  plan  is  no  longer  accurate. 
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proc  P6.j:  Software  Certification  for  Increment  j 

[P6.j  certifies  the  code,  and  makes  the  decision  as  to  whether  an  increment  will  be  accepted 
or  rejected.] 

do  [P6.j:  Software  Certification  for  Increment  j] 

C6.j.l:  Build  Accumulation  j; 
if  no  pre-certification  failures 

then 

while 

certification  plan  requires  more  tests  and  sufficient  failures  have  not  been  observed 
to  make  it  desirable  to  terminate  testing  and  wait  for  corrections 

do 

C6.j.2:  Perform  Certification  Tests  for  Accumulation  j; 

od; 

fi; 

if  at  least  one  failure  observed  and  observed  failures  are  considered  to  be  correctable 

then 

C6.j.3:  Prepare  failure  report(s); 

D6.j.4:  Correct  failure,  verify  correction  and  prepare  ECN; 

fi; 

M6.j.5:  Management  Decision:  (1)  certification  complete-accumulation  quality 
satisfactory,  (2)  certification  complete-quality  not  satisfactory-replanning  Is 
required  or  (3)  certification  should  continue; 
if  not  Management  Decision  is  certification  should  continue 

then 

C6.j.6:  Prepare  Certification  Report; 

fi; 

until 

Completion  Conditions  achieved  for  C6.j.6 

od; 

corp; 

It  is  not  feasible  to  provide  any  general  guidance  on  how  managers  should  go  about  making  these 
decisions.  Each  project  situation  and  the  associated  risks  will  be  different.  In  each  case  the 
manager  must  make  a  decision  that  reaches  the  proper  balance  between  risk  and  reward. 
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1.2  Completion  Conditions 

All  engineering  activities  in  the  process  model  are 

do 

until 


process  structures.  The  until  condition  are  called  Completion  Conditions.  They  are  a  series  of 
questions  that  can  be  answered  with  a  yes  or  no.  The  task  is  considered  complete  when  all 
questions  can  be  answered  with  a  yes.  In  the  Cleanroom  process,  all  Completions  Conditions 
must  be  answered  with  a  yes  by  all  members  of  the  team  that  is  responsible  for  the  task.  When 
this  occurs  the  activity  is  marked  as  complete  thus  authorizing  subsequent  activities  to  be 
initiated. 

The  Completion  Conditions,  while  all  viewed  as  objective  (yes/no)  decisions,  have  a  variety  of 
manifestations.  Some  of  the  tasks  have  Completion  Conditions  that  are  forms  with  some  number 
of  questions.  With  some  concurrent  tasks,  the  Completion  Conditions  for  the  concurrent 
activities  are  combined.  In  other  cases,  the  Completion  Conditions  are  based  on  control  flow 
conditions  of  the  Cleanroom  process  presented  in  Volume  1. 

The  Completion  Conditions  for  each  product  have  been  recorded  on  forms.  There  is  one  form 
for  each  engineering  activity.  Hard  copies  of  these  forms  are  included  in  section  4  of  this 
handbook  and  soft  copies  are  available  to  facilitate  their  use  in  managing  and  controlling  projects. 
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Cleanroom  Engineering  Project  Execution 


Section  2:  Dispatching 

In  the  Cleanroom  environment,  projects  are  process  driven.  Thai  means  the  dispatching 
decisions  are  made  by  using  the  process  definition  for  the  project  The  generic  process  definition 
is  contained  in  the  Software  Development  Plan.  The  process  definition  can  be  thought  of  as  a 
program  that  is  executed  by  the  managers  and  the  team  leaders.  In  one  software  project,  there 
will  be  one  active  process  definition  for  each  major  item  of  software.  In  2 167 A  language,  this 
means  one  active  process  for  each  Computer  Software  Configuration  Item  (CSCI). 

Each  active  process  definition  should  be  regarded  as  a  separate  sub-project.  The  parameters  that 
describe  the  project  may  change  during  the  project  as  a  result  of  replanning  decisions  and 
findings  about  the  program  structure.  These  changes  will  manifest  themselves  in  changes  to 
parameters  that  control  loops.  Typical  examples  are  the  number  of  specification  cycles  and  the 
number  of  increments. 

The  project  control  structure  is  defined  by  the  process  and  the  results  of  work  will  cause  different 
branchings  to  occur.  There  are  millions  of  possible  paths  through  the  control  structure.  As  the 
project  progresses  the  managers  must  keep  track  of  where  they  are  in  the  process  and  mak“  their 
next  dispatching  decision(s). 

Projects  are  executed  by  assigning  responsibility  for  performing  a  process  or  an  activity  to  a  team 
or  an  engineer.  The  control  flow  among  processes  and  activities  is  specified  in  terms  of 
sequential,  alternative,  iterative  and  concurrent  operations.  Therefore,  the  next  process  or  activity 
to  be  assigned  depends  on  the  realizations  of  prior  processes  and/or  activities  as  defined  by  the 
control  structure. 

Process  assignments  are  triggered  by  the  occurrence  of  a  project  event.  Project  events  occur 
whenever  a  team  or  person  that  is  responsible  for  a  process  or  activity  reports  that  an  activity  is 
complete  or  some  result  has  occurred  according  to  the  evaluation  of  some  predicate  in  the  control 
structure  that  defines  the  project  process.  Each  time  a  project  event  occurs,  it  is  necessary  for 
a  manager  or  team  leader  to  make  a  dispatching  decision  followed  by  assignment  of 
responsibility  to  some  team  or  person  for  the  next  activity  or  process  to  be  invoked.  The 
dispatching  decision  may  also  require  the  suspension  of  some  currently  assigned  processes  and/or 
activities. 

A  process  definition,  in  addition  to  the  control  flow,  must  define  the  data  flow  an  ong  activities. 
The  process  needs  to  define  the  data  (documents)  that  flows  into  the  activity  being  dispatched 
from  predecessor  activities  and  the  data  (documents)  that  is  to  flow  from  the  activity  when  the 
activity  is  complete.  In  the  Cleanroom  environment,  ail  data  or  document  files  are 
maintained  in  the  State  Data  Repository.  This  makes  the  definition  of  data  flow  quite  easy 
because  the  all  data  flows  to  and  from  one  place.  The  names  of  the  State  Data  Repository  files 
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associated  with  each  process  are  collected  in  a  table  for  easy  reference  in  the  Section  5  of  this 
handbook. 

The  integrity  of  the  state  data  repository  must  be  maintained  through  continuous,  rigorous 
configuration  management  Frequently  parts  of  the  state  data  repository  will  be  printed  out  and 
the  resulting  documents  used  to  support  work,  reviews,  etc.  These  documents  are  not  to  be 
considered  the  official  copy.  The  only  official  copy  is  the  soft  copies  in  the  state  data  repository. 

In  addition  to  the  control  flow  and  data  flow,  it  is  necessary  to  define  the  tools  that  will  be  used 
to  support  each  of  the  processes.  The  required  tools  for  each  process  are  again  defined  in  a  table 
included  in  Section  5  of  this  handbook. 

To  maintain  the  project  in  intellectual  control  the  managers  need  to  manage  the  project  to  the 
process  definition.  That  means  they  need  to  understand  the  process  and  know  where  they  are  in 
the  process  at  all  times.  This  can  be  done  in  several  ways. 

Manual  -  Informal  In  this  case,  the  managers  understand  the  process  so  well  that  they  can 
keep  track  of  the  process  and  progress  in  executing  the  process  in  their  head,  perhaps 
consulting  generic  process  for  guidance  when  needed.  This  seems  to  work  quite  well  for 
small  projects  that  are  being  performed  by  well  trained  teams. 

Manual  -  Forms  Based  In  this  case,  the  process  as  defined  for  each  project  is  recorded  on 
a  series  of  forms.  Progress,  branching  decisions,  dates  and  current  assignments  are  recorded 
on  the  form.  The  form  is  used  to  support  the  making  of  dispatching  decisions,  recording 
progress  and  reporting  on  status.  These  forms  can  either  be  maintained  in  hard  or  soft  copy 
formats.  Forms  are  maintained  current  with  progress  with  executing  the  process.  The  details 
of  a  forms  driven  system  are  discussed  in  section  2.1.  This  is  the  type  of  Process 
Management  System  that  will  be  defined  for  the  COFT  project. 

Automated  In  this  case,  the  process  is  defined  to  a  program  and  as  the  program  executes  it 
keeps  track  of  progress  and  control  decisions.  The  team  leader  or  manager  tells  the  program 
who  is  to  do  what  The  program  then  automatically  releases  the  work  on  the  appropriate 
work  station.  The  system  can  help  the  manager  prepare  status  reports.  Process  management 
programs  are  only  in  the  preliminary  stages  of  development.  Some  prototypes  are  available. 
CEPA  which  is  designed  for  Cleanroom  is  an  advanced  example  of  this  class  of  program. 
CEPA  is  discussed  in  section  2.2.  CEPA  will  be  used  to  support  the  MBC  project. 

Dispatching  decisions  are  made  by  the  Software  Engineering  Manager,  team  leaders  and 
engineers.  Which  dispatching  decisions  are  to  made  are  summarized  in  the  tasks  defined  in  the 
process.  Software  Engineering  Managers  assign  processes  to  team  leaders.  Team  leaders  assign 
activities  to  team  members. 
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2.1  A  Forms  Driven  Process  Management  System 
The  elements  of  the  form  driven  system  are: 

A  set  of  Project  Process  Management  Forms  that  define  the  process  and  the  current  status 
of  the  process  for  the  project  A  master  set  of  these  forms  for  the  generic  process  model 
defined  in  Volume  1  are  included  in  section  5. 

A  dispatching  form  used  by  the  Software  Engineering  Manager  and  Team  Leaders  to  issue 
dispatching  systems.  The  Project  Process  Management  Forms  have  been  designed  to  serve 
also  as  the  dispatching  form. 

A  set  of  project  management  files  located  in  the  state  data  repository.  These  files  contain 
soft  copies  of  all  Project  Process  Management  Forms. 

Software  Master  Plan  showing  the  activities  down  to  the  planning  level  work  break  down 
structure  (Figure  3.3  in  Volume  1).  This  plan  is  used  to  support  the  person  making  a 
dispatching  decision. 

A  notebook  that  contains  the  current  Process  Management  Forms  and  Software  Master  Plan. 
The  notebook  is  used  to  support  Project  Process  Management  Meetings.  Each  team  member 
has  a  copy  so  he  or  she  can  understand  the  project  status.  In  what  follows  we  assume  the 
notebook  color  is  green  and  we  refer  to  the  Project  Process  Management  meeting  as  the 
Green  book  meeting. 

Green  book  meetings.  Frequently  the  staff  will  meet  to  review  the  status  of  the  process.  The 
notebooks  will  be  used  to  run  these  meetings.  The  actual  frequency  will  be  based  on  the 
needs  of  the  project.  It  would  be  rare  that  a  weekly  meeting  would  not  be  beneficial.  A 
typical  agenda  for  a  green  book  meeting  is: 

•  Review  Upcoming  Project  Calendar 

•  Specification  Process  Status  and  Prospects  -  Specification  Team  Leader 

•  Development  Process  Status  and  Prospects  -  Development  Team  Leader 

•  Certification  Process  Status  and  Prospects  -  Certification  Team  Leader 

•  Project  Status  and  Prospects  -  Software  Engineering  Manager 

•  Review  Action  Items 

•  Assign  Action  Items 

•  Dispatching  Assignments 

•  Other  Items 

There  are  two  aspects  that  must  be  defined  in  how  to  use  the  Project  Process  Management  Forms 
V)  manage  the  project  using  the  process.  The  system  must  be  initialized  for  a  new  project  and 
the  system  must  be  executed  during  the  course  of  the  project.  The  steps  that  must  be  performed 
are: 
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Establishing  A  New  Project 

1.  Copy  the  Master  Process  Management  Forms  to  a  file  of  Project  Process  Management  Forms 
for  the  project 

2.  Use  the  facilities  of  the  word  processor  to  do  at  least  the  following: 

•  specialize  the  process  for  the  project 

•  update  the  forms  to  include  the  project  name  and  the  spiral  identification, 

•  include  multiple  copies  of  forms  related  to  process  P4  for  each  planned  specification 
cycle  and  PS  and  P6  for  each  planned  increment  and 

•  complete  forms  related  to  process  P4  and  P5  to  a  one  page  reference  to  help  track  the 
multiple  copies  of  Process  Management  Forms  created  for  these  processes. 

3.  Incorporate  project  plan  dates  and  other  related  dates  on  to  the  Project  Process  Management 
Forms. 

4.  Print  out  the  forms  and  file  them  in  the  Project  Process  Management  Notebook.  It  is  a  good 
practice  to  select  a  notebook  color  for  the  project,  say  green.  Then  the  notebook  can  be 
referred  to  as  the  green  book  and  project  meetings  to  control  the  process  can  be  referred  to 
as  green  book  meetings. 

5.  Establish  a  frequency  and  a  typical  agendas  for  project  process  management  meetings. 
Meetings  should  be  short  Their  purpose  is  to  review  the  status  of  the  process  and  the 
project,  define  action  items  -  not  resolve  problems,  make  announcements  and  assign 
responsibilities  for  processes  and  tasks.  A  typical  agenda  for  a  Green  Book  meeting  was 
presented  on  the  previous  page. 

Executing  The  Process  For  A  Project 

Projects  are  executed  by  assigning  responsibility  for  performing  a  process  or  an  activity  to  a  team 
or  an  igineer.  The  control  flow  among  processes  and  activities  is  specified  in  terms  of 
sequential,  alternative,  iterative  and  concurrent  operations.  Therefore,  the  next  process  or  activity 
to  be  assigned  depends  on  the  realizations  of  prior  processes  and/or  activities  as  defined  by  the 
control  structure. 

Process  assignments  are  triggered  by  the  occurrence  of  a  project  event  Project  events  occur 
whenever  a  team  or  person  that  is  responsible  for  a  process  or  activity  reports  that  an  activity  is 
complete  or  some  result  has  occurred  according  to  an  evaluation  some  predicate  in  the  control 
structure  that  defines  the  project  process.  In  the  Cleanroom  environment  project  events  normally 
occur  by  the  completion  of  Completion  Condition  forms.  Each  time  a  project  event  occurs  it  is 
necessary  for  a  manager  or  team  leader  to  make  a  dispatching  decision  followed  by  assignment 
of  responsibility  to  some  team  or  person  for  the  next  activity  or  process  to  be  invoked.  The 
dispatching  decision  may  also  require  the  suspension  of  some  currently  assigned  processes  and/or 
activities. 


ID52  -  Vol.  3  -  Project  Execution  in  Cleanroom 


Page  12 


The  Project  Process  Management  Forms  have  been  used  to  help  managers,  team  leaders  and 
engineers  manage  and  control  the  project  according  the  project  process.  They  can  be  used  as 
follows: 

1.  Each  time  a  project  event  occurs,  the  status  of  the  project  is  updated  on  the  Project  Process 
Management  Form. 

2.  The  control  structure  is  evaluated  and  the  next  process  or  activity  that  is  to  be  performed  is 
determined.  The  person  who  is  responsible  for  making  the  dispatching  decision  and  then 
making  the  assignment  uses  his/her  knowledge  and  expertise  to  reach  a  decision.  The 
decision  is  then  recorded  on  the  Project  Process  Management  Form  by  either  creating  a  new 
form  or  updating  the  right  line  on  an  existing  form. 

3.  The  actual  assignment  is  made  by  giving  the  person  or  team  leader  a  copy  of  the  updated  or 
new  Project  Process  Management  Form.  In  actual  practice  the  assignment  may  be  made 
verbally  and  the  updated  or  new  form  is  distributed  with  the  next  edition  of  the  project  green 
book. 

4.  Periodically  a  complete  set  of  the  then  active  Project  Process  Management  Forms  are 
distributed  to  all  project  participants.  This  distribution  is  made  just  before  or  just  after  a 
green  book  meeting. 

5.  Green  book  meeting  are  held  periodically,  say  weekly.  At  these  meetings  the  Project  Process 
Management  Forms  are  reviewed.  In  this  way  the  responsible  persons  can  access  progress 
and  potential  problems  and  take  timely  action  as  required. 

2.2  CEPA:  An  Automated  Process  Management  System 

The  Cleanroom  Engineering  Process  Assistant  (CEPA)  is  a  prototype  Process  Management 
System  which  has  been  designed  to  help  organizations  utilize  the  Cleanroom  process.  CEPA  has 
been  developed  with  support  from  the  DARPA/STARS  program  and  is  being  made  available  for 
use  by  the  MBC  project  at  Picatinny  by  DARPA.  Since  CEPA  is  a  prototype  it  is  not  yet 
complete  but  it  is  believed  to  have  sufficient  functionality  to  provide  significant  support  to  the 
MBC  project. 

The  mission  of  CEPA  is  to  enable  software  development  organizations  using  the  Cleanroom 
process  to  produce  high  quality  products  while  increasing  productivity.  The  realization  of  CEPA 
is  as  a  software  engineering  environment  (SEE)  architecture  and  a  set  of  computer-aided  software 
engineering  (CASE)  servers  that  support  the  Cleanroom  process  by  managing  the  work  activities 
and  information  of  Cleanroom. 

The  CEPA  approach  is  innovative  in  that  CEPA  provides  a  top  down  approach  to  automating  the 
Cleanroom  process.  For  process  support,  one  must  first  define  and  understand  the  process,  then 
must  support  the  process.  Only  after  supporting  the  process  is  it  useful  to  support  process  steps. 
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since  die  steps,  and  therefore  the  tools  must  fit  together  and  co-exist  The  Cleanroom  process 
is  defined  and  understood.  CEPA  supports  the  Cleanroom  process,  and  provides  a  framework 
for  further  support  of  process  steps.  In  other  words,  tools  that  will  assist  an  engineer  in 
completing  part  of  the  Cleanroom  process  fit  into  CEPA,  and  are  made  available  as  needed.  In 
that  manner,  tools  can  fit  in  the  manner  that  makes  Cleanroom  performance  most  effective. 

The  CEPA  mission  is  accomplished  by  providing  on-line  assistance  to  all  members  of  the 
software  engineering  team  in  utilizing  the  Cleanroom  process.  The  Cleanroom  process  has  been 
shown  to  facilitate  the  development  of  essentially  defect-free  programs  and  to  increase  the 
development  team’s  productivity.  CEPA  facilitates  managing  and  following  the  Cleanroom 
process,  which  allows  Cleanroom  projects  to  realize  even  greater  benefits.  CEPA  will  have  the 
following  missions  in  aiding  members  of  the  development  team  to  use  the  Cleanroom  process: 

1.  to  reduce  the  time  lost  because  supporting  activities  are  not  properly  coordinated.  CEPA  will 
significantly  improve  the  probability  that  all  of  the  pre-requisites,  tools,  and  data  that  an 
engineer  needs  to  do  a  task  are  available  with  no  wasted  time  on  his  or  her  part 

2.  to  make  it  easier  for  the  engineer  to  follow  the  Cleanroom  process,  and  thereby  obtain  all 
of  its  benefits. 

3.  to  enforce  the  Cleanroom  process  in  the  most  unobtrusive  way  possible  by  being  user- 
friendly. 

4.  to  facilitate  for  all  levels  of  management  the  ability  to  plan,  schedule  and  control  all  project 
tasks  and  to  insure  that  the  required  reviews  and  verifications  take  place. 

5.  to  improve  collection  of  all  required  metrics  for  providing  statistical  control  of  the 
development  process. 

6.  to  update  on-line  state  data,  which  is  the  data  needed  to  devHop  the  product,  and  make  it 
immediately  available  to  all  members  of  the  development  group. 

7.  to  provide  direct,  on-line  access  to  standards,  tutorials  and  other  aids. 

8.  to  improve  formal  and  informal  communication  between  the  members  of  the  project  team. 

In  regards  to  an  automated  process  management  system,  the  first  and  fourth  points  above  have 
meaning.  CEPA  does  handle  the  dispatching  responsibility  for  the  parts  of  the  Cleanroom 
process  that  appear  within  its  functionality.  That  functionality  is  a  significant  portion  of  what 
appears  in  the  procedural  definition  of  the  Cleanroom  process  found  in  Volume  1.  Since  CEPA 
is  still  a  prototype,  the  functionality  of  CEPA  is  not  complete  with  regards  to  that  process 
definition.  So  there  are  some  tasks  that  will  be  done  manually,  which  puts  them  out  of  the 
control  of  CEPA. 
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In  regards  to  the  dispatching  functionality  available  to  CEP  A,  a  user  can  assign  tasks  to  other 
users  or  teams,  which  only  appear  on  the  other  user’s  pick  list  when  the  task  is  available  to  be 
worked  on,  ie,  all  necessary  information  to  work  on  the  task  is  available.  Additionally,  CEPA 
will  make  files  inaccessible  for  update  while  a  specific  task  is  in  review,  and  will  mark 
completed  tasks  as  such.  In  this  manner,  CEPA  does  keep  status,  and  can  return  to  a  user  the 
full  status  of  all  tasks  that  are  handled  within  CEPA  during  the  project  Tasks  can  be  reassigned 
to  individuals  if  the  need  arises  and  individuals  can  be  added  to  or  deleted  from  a  project. 

CEPA  does  not  yet  provide  the  team  leader  or  manager  with  sufficient  information  to  enable 
them  to  fully  control  the  project  CEPA  does  not  currently  have  a  mapping  of  activities  to  a 
schedule,  that  is,  task  assignments  and  tasks  do  not  have  a  notion  of  time  associated  to  them. 
Therefore,  CEPA  cannot  consider  tasks  to  be  ahead  or  behind  schedule,  and  cannot  inform 
engineers  or  managers  that  a  schedule  is  slipping.  Additionally,  the  portions  of  the  Cleanroom 
process  that  are  not  within  the  realm  of  CEPA  are  not  known  to  CEPA,  and  therefore  cannot  be 
controlled. 

For  the  reasons  stated  above,  it  is  necessary  to  use  die  forms  developed  for  the  forms  based 
dispatching  system  to  support  project  and  team  management  and  to  record  project  status.  These 
forms  can  be  used  with  CEPA  in  the  following  manner: 

1)  All  tasks  assignments  made  during  the  Cleanroom  project  are  made  using  the  dispatching 
forms. 

2)  For  tasks  that  are  not  done  using  CEPA,  the  forms  based  approach  is  followed  completely. 

3)  For  tasks  that  are  completed  by  using  CEPA,  forms  should  be  distributed  so  as  to  inform  the 
assignee  of  the  relationship  of  the  particular  task  to  the  schedule.  But  instead  of  requiring 
the  engineer  to  continually  return  task  status,  the  team  leader  or  manager  can  use  CEPA  to 
determine  the  current  status  of  tasks.  In  the  event  that  CEPA  does  not  provide  sufficient 
information  for  particular  tasks,  the  paper  trail  of  the  forms  based  approach  can  be  reinstated. 
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Section  3:  Metrics  Collection 


Measurements  are  required  to  effectively  support  the  appraisal  and/or  modification  of  any 
engineering  process.  With  Cleanroom,  metrics  play  an  important  role  in  appraising  both  the 
process  and  the  product  of  the  process.  The  metrics  to  be  discussed  in  this  section  are  those  that 
relate  to  Project  Execution,  that  is,  for  process  appraisal  during  a  project  and  for  status  reporting 
to  other  stakeholders  in  the  project  Metrics  that  impact  Organization  Formation  and  process 
improvement  efforts  are  discussed  in  section  2.3  of  Volume  2. 

The  measurements  collected  in  a  Cleanroom  project  can  be  classified  into  8  categories  as  listed 
below.  Some  of  the  measures  are  based  on  direct  observations  and  others  require  calculation. 

Metrics  Based  On  Observation: 

Effort 

Status 

Schedule 

Library  Management 
Correctness  History 

Metrics  Based  On  Calculation: 

Productivity 
Quality 
Cycle  Time 

Each  of  the  metrics  consist  of  the  following  specified  measures: 


Category 

Measure(s)  Per  Category 

Effort 

a)  Technical  staff  hours  per  process/task 

Schedule 

b)  Current  and  projected  schedules 

Status 

c)  Tasks  assigned 

d)  Current  statuses  of  tasks  assigned 
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Library 

Management 

e)  Numbers  of  new  components 

f)  Sizes  (Lines  of  Code)  of  new  components 

g)  Numbers  of  modified  components 

h)  Size  (Lines  of  Code)  of  modified  components 

i)  Numbers  of  reused  components 

j)  Size  (Lines  of  Code)  of  reused  components 

k)  Test  scenarios  developed  per  accumulation 

l)  Size  of  all  components  changed  after  first  entry  into  library,  per 
submission. 

Correctness 

History 

m)  Software  system  configuration  per  test  suite 

n)  Execution  result  per  test  case  execution  | 

o)  Failure  reports  I 

p)  Engineering  change  notices  f 

Productivity 

q)  Effort  per  lines  of  code  developed  | 

Quality 

r)  Failures  and  corrections  per  thousand  lines  of  code  developed 

s)  Projected  and  actual  reliability  of  software  system  versions 

Cycle  Time 

t)  Projected  and  actual  cycle  time  for  project 

The  collection  of  these  measures  ought  to  be  a  normal  part  of  the  work  products  and  other 
management  activities  produced  by  the  organization.  The  rate  at  which  each  of  these  measures 
are  gathered  will  vary  according  to  what  is  most  efficient  within  the  organization. 

These  measures  can  be  collected  as  described  in  the  following  sections: 

Effort 

Effort  measures  need  to  be  collected  for  each  activity.  This  means  that  the  organization’s  time 
accounting  system  needs  to  be  modified  to  enable  each  project  participant  to  allocate  time  spent 
to  the  activities.  It  is  suggested  that  the  codes  used  to  identify  the  activities  in  the  process 
definition  are  used  as  reference  for  the  measures  to  be  collected.  The  activities  for  which  metrics 
should  be  collected  are  listed  in  Figure  3.3  of  Volume  1. 

The  effort  metrics  should  be  accumulated  for  each  time  period  and  then  reported  in  the  Green 
book.  Any  significant  variations  between  the  plan  and  actuals  must  be  discussed  in  the 
appropriate  status  report 

Schedule  and  Status 


These  measures  are  maintained  on  the  Project  Process  Management  Forms.  The  current 
information  is  in  the  Green  book.  Historical  records  are  in  the  soft  copies  of  these  forms  as 
maintained  in  the  state  data  repository. 
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Library  Management 


All  the  design  objects  are  maintained  in  the  state  data  repository.  There  are  commercial 
programs  such  as  CCC  and  CMS  that  can  be  used  to  analyze  the  boxes  and  prepare  the  required 
measures.  It  is  important  that  this  information  be  prepared  directly  from  the  state  data  repository 
to  insure  its  accuracy.  These  activities  can  be  handled  by  team  leaders  when  completing  status 
reports. 

The  state  data  repository  should  be  analyzed  frequently,  say  monthly,  and  interim  information 
should  be  reported  in  the  appropriate  status  reports. 

Correctness  History 

All  of  these  measures  are  contained  in  the  certification  report  for  each  increment.  On-going 
reports  of  these  measures  should  be  a  regular  part  of  the  certification  team  leaders  status  report. 

Productivity,  Quality  and  Cycle  Time 

Actual  and  project  completion  estimates  should  be  developed  each  month  by  the  Software 
Engineering  Manager  and  included  in  the  monthly  project  status  report  so  that  all  project 
participants  continue  to  focus  on  these  bottom  line  measures. 
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Cleanroom  Engineering  Project  Execution 
Section  4:  Completion  Conditions 

In  this  section,  forms  that  define  the  Completion  Conditions  for  each  of  the  Cleanroom 
Engineering  tasks  have  been  collected.  The  forms  have  been  grouped  into  four  sections,  one  for 
each  team  and  a  fourth  section  for  selected  management  tasks.  These  forms  are  suitable  for 
reproduction  so  they  can  be  completed  by  team  members  following  a  review.  Soft  copies  are 
also  available  so  team  members  can  fill  them  out  on  line  and  prepare  forms  for  manual  entry. 
In  either  case,  the  forms  must  be  filed  for  reference. 
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Completion  Condition  Forms 
for 

Specification  Team  Tasks 
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Task  S4.L2.1  Information  Collection 


Cycle  (i): _ Project _  Team: _  Date: _ 

Y  /  N  Completion  Condition  Question: 

1)  Have  all  potential  sources  of  information  from  the  problem  domain  been 
considered? 

la)  Has  information  been  gathered  from  system  users? 

lb)  Has  information  been  gathered  from  system  managers? 

lc)  Has  information  been  gathered  from  application  domain  experts? 

ld)  Has  information  been  gathered  from  other  classes  of  system  customers? 

2)  Have  the  planned  sources  of  information  been  approached  and  information 
gathered? 

3)  Has  insights  gained  been  documented? 

4)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Task  S4.i.2.2  Assemble  Information  Required  for  Reverse  Engineering  of  System 


Cycle  (i): _ Project: 


Team: 


Date: 


I  Y/N 

Completion  Condition  Question: 

1)  Have  the  systems  to  be  reverse  engineered  been  identified? 

2)  Have  the  boundaries  for  systems  to  be  analyzed  been  properly  defined? 

3)  Have  all  useful  sources  of  information  to  support  the  reverse  engineering 
effort  for  each  system  been  identified? 

3a)  Does  development  information  exist? 

3b)  Is  documentation  available? 

3c)  Is  program  code  available? 

3d)  For  manual  systems,  are  SOP’s  available? 

3e)  Have  customers,  users  and  managers  been  interviewed? 

4)  Has  all  necessary  information  been  cataloged  and  where  required  stored  in 
the  state  data  repository? 

5)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Task  S4.L2.3  Manual  System  Reverse  Engineering 
Task  S4.i.2.4  Automated  System  Reverse  Engineering 
Task  S4.i.2.5  Hybrid  System  Reverse  Engineering 


Cycle  (i): _ Project: _  Team: _  Date: 


1  Y/N 

Completion  Condition  Question: 

1)  Have  the  processes  observed  or  researched  been  documented? 

2)  Have  the  results  of  the  analysis  task  been  documented? 

3)  Has  a  usage  hierarchy  of  system  components  been  discovered? 

: 

4)  Has  the  top  level  black  box  model  of  each  system  been  discovered? 

5)  Is  the  black  box  model  sufficient  for  the  intended  purpose?  Do  system 
stakeholders  agree  that  it  is  accurate? 

6)  Have  all  useful  abstractions  developed  during  the  analysis  been  placed  in  a 
reuse  repository  for  potential  reuse  by  the  development  team? 

7)  Has  a  memo  defining  observed  discrepancies  been  prepared  to  assist  in 
defining  the  new  system?  f 

8)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data  1 

been  completed? 
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Task  S4.i.2.6  Develop  and  Analyze  Black  Box  Model 


Cycle  (i): _ Project; _  Team; _  Date: 


Y/N 

Completion  Condition  Question:  1 

1)  Have  all  known  transactions  been  described  using  black  boxes? 

2)  Have  any  known  transitions  been  described  using  black  boxes? 

3)  Has  all  known  black  box  behavior  been  documented  in  a  transaction  fl 

hierarchy? 

4)  Has  the  behavior  of  the  black  box  model  been  analyzed? 

5)  Have  the  results  of  the  analysis  been  documented? 

5a)  Is  model  consistent? 

5b)  Does  transaction  closure  exist? 

5c)  Is  the  model  clear? 

6)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Task  S4.L2.7  Develop  and  Analyze  Markov  Usage  Model 

Cycle  (i): _ Project: _  Team: _  Date: 


Y/N 

Completion  Condition  Question: 

1)  Have  all  appropriate  classes  of  users  been  identified? 

2)  Have  all  usage  states  been  identified? 

3)  Has  a  usage  model  of  the  system  been  defined  for  each  class  of  user? 

3a)  Are  all  transition  possibilities  identified? 

3b)  Have  all  transition  probabilities  been  identified? 

4)  Is  the  model  consistent  with  the  Markov  property? 

5)  If  usage  analysis  was  done,  have  the  results  been  documented?  1 

6)  Has  the  model  been  evaluated  using  Markov  calculations?  1 

7)  Is  the  Markov  Model  consistent  with  the  Black  Box  function? 

8)  Has  the  model  been  reviewed  with  all  appropriate  stakeholders?  Do  they 
think  the  model  is  appropriate  for  its  intended  purpose? 

9)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data  1 

been  completed?  1 
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Task  S4.L3.1  Information  Collection 


Cycle  (i): _ Project: 


Team:. 


Date: 


I  Y/N 

Completion  Condition  Question: 

1)  Have  all  potential  sources  of  information  from  the  solution  domain  been 
considered? 

la)  Has  information  on  Organizational  Architectures  been  gathered? 

lb)  Have  reuse  libraries  been  identified  and  accessed? 

lc)  Have  benchmarking  studies  of  best-in-class  processes  been  performed? 

ld)  Have  similar  systems  been  identified  and  studied? 

le)  Have  technical  experts  been  consulted? 

2)  Have  the  planned  sources  of  information  been  approached  and  information 
gathered? 

3)  Have  insights  gained  been  documented? 

4)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Task  S4.L3.2  Browse  Reuse  Repository  To  Find  Match  For  Needs 
Task  S4.i.3.3  Prepare  Cost/Benefit  Analysis 

Task  S4.i.3.4  Select  Potential  Reuse  Modules  for  Integration  into  System 
Cycle  (i): _ Project: _  Team: _  Date: 


Y/N 

Completion  Condition  Question: 

1)  Have  potentially  reusable  objects  been  gathered? 

2)  Have  exact  and  partial  matches,  in  terms  of  potentially  reusable  objects, 
been  noted  as  such? 

3)  Has  an  analysis  for  a  make/buy  decision  for  each  object  been  done?  Are  the 
analyzes  documented  in  trade  studies? 

4)  Have  the  make/buy  decisions  been  made  for  each  object? 

5)  For  partial  matches,  has  the  extent  of  modification  been  planned  for  and 
understood? 

u 

6)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Task  S4.L3.5  Determine  Black  Box  Behavior  Of  Other  Solution  Domain  Objects 
Cycle  (i): _ Project: _  Team: _  Date: 

1)  Have  all  external  objects  been  listed? 

2)  Has  the  behavior  related  to  the  system  being  developed  been  clearly 
understood? 

3)  Has  the  necessary  behavior  been  described  using  black  boxes? 

4)  Have  all  system  interfaces  with  external  objects  been  identified  and 
understood? 

5)  Has  all  analysis  been  documented? 

6)  Do  the  experts  in  the  system  objects  agree  that  the  model  of  the  object  they 
understand  is  correct? 

7)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 


Completion  Condition  Question: 


Y/N 
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Task  S4.i.3.6  Develop  prototype  software  using  Cleanroom  practices 

Cycle  (i): _ Project: _  Team: _  Date: _ 

1)  Is  the  prototype  objective  clearly  understood  and  is  its  cost  justifiable? 

2)  Have  Cleanroom  practices  been  followed  in  developing  the  prototype? 

3)  Is  the  specification  for  the  prototyping  effort  consistent  with  the  prototyping 
mission? 

4)  Has  the  design  trail  for  the  prototype  been  preserved? 

5)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 


Completion  Condition  Question: 


Y/N 
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Task  S4.i.3.7  Conduct  and  appraise  prototype  experiment 

Task  S4.i.3.8  Store  prototype  components  in  project  reuse  repository 

Cycle  (i): _ Project: _  Team: _  Date: _ 

Y  /  N  Completion  Condition  Question: 

1)  Have  all  desired  experiments  been  conducted  with  the  prototype? 

2)  Have  the  results  of  all  prototype  experiments  been  documented? 

3)  Has  the  plan  for  each  prototype  experiment  been  documented? 

4)  Has  the  prototype  been  appraised  in  regards  to  the  prototyping  effort’s 
mission? 

5)  Is  the  entire  design  trail  for  the  prototype  complete? 

6)  Is  the  certification  trail  for  the  prototype  complete? 

7)  Are  the  prototype’s  specifications  consistent  with  the  implemented 
prototype? 

8)  Have  the  experimental  results  based  on  using  the  prototype  been  appraised 
in  regards  to  the  prototyping  effort’s  mission? 

I  9)  Have  the  results  of  the  prototype  experiment  been  integrated  into  the  system 

specification? 

10)  Has  the  entire  development  trail  for  the  prototype  been  placed  in  the  state 
data  repository? 

Ill)  Has  the  specification  trail  for  the  prototype  been  placed  in  the  state  data 
repository? 

12)  Has  the  certification  trail  for  the  prototype  been  placed  in  the  state  data 
repository? 

113)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Task  S4.i.4.1  Record  Cycle  i  Results  in  Mission  Volume 


Cycle  (i): _ Project: _  Team: _  Date: 


Y/N 

Completion  Condition  Question: 

1)  Does  the  Mission  Statement  present  all  of  the  stakeholder’s  requirements  for 
the  software? 

2)  Are  all  statements  clearly  defied  as  a  requirement,  constraint  or  objective. 

3)  Are  all  requirements  clear,  consistent  and  unambiguous? 

4)  Is  each  requirement  fully  justified  with  a  supporting  argument? 

5)  Is  the  Mission  Statement  consistent  with  regards  to  the  other  volumes  of  the 
cycle? 

6)  Has  the  Mission  Statement  been  reviewed  by  the  other  members  of  the 
specification  team? 

7)  Have  all  editors  for  the  Mission  Statement  returned  their  comments? 

8)  Have  all  readers  for  the  Mission  Statement  returned  their  comments?  1 

9)  Have  the  external  stakeholders  had  the  opportunity  to  review  the  Mission 
Statement?  Do  they  all  agree  the  volume  fully  and  completely  defines  the 
mission  of  the  software? 

10)  Is  the  mission  a  mission  for  a  software  system? 

_ 

1 1)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Task  S4.i.4.2  Record  Cycle  i  Results  in  User’s  Reference  Manual  Volume 


Cycle  (i):_ 


Project. 


Team: 


Date: 


Y/N 

Completion  Condition  Question: 

1)  Does  the  User’s  Reference  Manual  present  all  of  the  stakeholder’s  external 
requirements  for  the  software? 

2)  Are  users  and  other  stakeholders  in  the  system  fully  satisfied  with  the 
definition  of  all  stimuli  and  responses? 

3)  Are  all  stimuli  and  responses  software  stimuli  and  responses? 

4)  Are  all  stimuli  and  responses  consistent  with  the  black  box  function? 

5)  Is  the  Users  Reference  Manual  clearly  and  well  written?  Is  it  written  from 
the  perspective  of  the  user  of  the  software?  Can  a  subject  matter  expert  use 
the  software  using  only  the  users  reference  manual? 

6)  Is  the  User’s  Refeionce  Manual  consistent  with  regards  to  the  other  volumes 
of  the  cycle? 

7)  Has  the  User’s  Reference  Manual  been  reviewed  by  the  other  members  of 
the  specification  team? 

8)  Have  all  editors  for  the  User’s  Reference  Manual  returned  their  comments? 

5)  Have  all  readers  for  the  User’s  Reference  Manual  returned  their  comments? 

9)  Have  the  external  stakeholders  had  the  opportunity  to  review  the  User’s  1 

Reference  Manual?  Do  they  all  agree  the  volume  fully  and  completely  defines  1 
the  mission  of  the  software?  B 

10)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Task  S4.i.4.3  Record  Cycle  i  Results  in  Black  Box  Function  Volume 


Cycle  (i): _ Project: _  Team: _  Date: 


Y/N 

Completion  Condition  Question: 

1)  Does  the  Functional  (Black  Box)  Specification  present  all  of  the 
stakeholder’s  behavioral  requirements  for  the  software? 

2)  Are  black  box  and  users  reference  manual  stimuli  and  responses  completely 
consistent? 

3)  Has  the  behavior  of  the  black  box  model  been  analyzed? 

4)  Have  the  results  of  the  analysis  been  documented? 

4a)  Is  model  consistent? 

4b)  Does  transaction  closure  exist? 

4c)  Is  the  model  clear? 

5)  Is  the  Functional  (Black  Box)  Specification  consistent  with  regards  to  the 
other  volumes  of  the  cycle? 

6)  Has  the  Functional  (Black  Box)  Specification  been  reviewed  by  the  other 
members  of  the  specification  team? 

7)  Have  all  editors  for  the  Functional  (Black  Box)  Specification  returned  their 
comments? 

8)  Have  all  readers  for  the  Functional  (Black  Box)  Specification  returned  their 
comments? 

9)  Have  the  external  stakeholders  had  the  opportunity  to  review  the  Functional  1 
(Black  Box)  Specification?  Do  they  all  agree  the  volume  fully  and  completely  | 
defines  the  mission  of  the  software? 

10)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Task  S4.i.4.4  Record  Cycle  i  Results  in  Mission  Validation  Volume 

Cycle  (i): _ Project: _  Team: _  Date: _ 

Y  /  N  Completion  Condition  Question: 

1)  Does  the  Specification  Validation  prove  the  consistency  between  the  Mission 
Statement/User’s  Reference  Manual  and  the  Black  Box? 

2)  Is  the  Specification  Validation  consistent  with  regards  to  the  other  volumes 
of  the  cycle? 

3)  Has  the  Specification  Validation  been  reviewed  by  the  other  members  of  the 
specification  team? 

4)  Have  all  editors  for  the  Specification  Validation  returned  their  comments? 


! 

j 


5)  Have  all  readers  for  the  Specification  Validation  returned  their  comments? 

6)  Have  the  external  stakeholders  had  the  opportunity  to  review  the 
Specification  Validation?  Do  they  accept  the  argument? 

7)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Task  S4.L4.5  Record  Cycle  i  Results  in  Usage  Profile  Volume 

Cycle  (i): _ Project: _  Team: _  Date: _ 

Y  /  N  Completion  Condition  Question: 

1)  Does  the  Usage  Profile  present  all  of  the  stakeholder’s  usage  requirements 
for  the  software? 

2)  Have  all  appropriate  classes  of  users  been  identified? 

3)  Have  all  usage  states  been  identified? 

4)  Has  a  usage  model  of  the  system  been  defined  for  each  class  of  user? 

4a)  Are  all  transition  possibilities  identified? 

4b)  Have  all  transition  probabilities  been  identified? 

5)  Is  the  model  consistent  with  the  Markov  property? 

6)  If  usage  analysis  was  done,  have  the  results  been  documented? 

7)  Has  the  model  been  evaluated  using  Markov  calculations? 

8)  Is  the  Markov  Model  consistent  with  the  Black  Box  function? 

9)  Has  the  model  been  reviewed  with  all  appropriate  stakeholders?  Do  they 
think  the  model  is  appropriate  for  its  intended  purpose? 

10)  Is  the  Usage  Profile  consistent  with  regards  to  the  other  specification 
volumes  of  the  cycle? 

11)  Has  the  Usage  Profile  been  reviewed  by  the  other  members  of  the 
specification  team? 

12)  Have  all  editors  for  the  Usage  Profile  returned  their  comments? 

13)  Have  all  readers  for  the  Usage  Profile  returned  their  comments? 

14)  Have  the  external  stakeholders  had  the  opportunity  to  review  the  Usage 
Profile?  Do  they  all  agree  the  volume  fully  and  completely  defines  the  mission 
of  the  software? 
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15)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Task  S4.L4.6  Record  Cycle  i  Results  in  Construction  Plan  Volume 


Cycle  (i): _ Project; _  Team: _  Date: 


Y/N 

Completion  Condition  Question: 

1)  Does  the  construction  plan  provide  for  user  executable  increments  for  every 
accumulation  of  increments? 

2)  Does  the  final  increment  of  the  construction  plan  provide  the  full 
functionality? 

3)  Has  the  construction  plan  decomposed  the  system  into  increments  so  as  to 
minimize  problems  for  the  development  team(s)? 

4)  Is  the  Construction  Plan  consistent  with  regards  to  the  other  volumes  of  the 
cycle? 

5)  Has  the  Construction  Plan  been  reviewed  by  the  other  members  of  the 
specification  team? 

6)  Have  all  editors  for  the  Construction  Plan  returned  their  comments? 

7)  Have  all  readers  for  the  Construction  Plan  returned  their  comments? 

8)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Task  S5.j.l.l  Tailor  specification  to  increment/accumulation  j 
Task  S5.j.l.2  Tailor  Usage  Profile  to  increment/accumulation  j 


Cycle  (i):_ 


Project.. 


Team: 


Date: 


Y/N 

Completion  Condition  Question: 

1)  Has  a  Black  Box  and  Usage  Profile  been  prepared  for  the  increment  from 
the  parent  volumes  according  to  the  construction  plan? 

2)  Are  the  tailored  volumes  complete?  Have  they  been  placed  in  the  state  data  H 
repository?  j 

3)  Does  the  accumulatuion  of  tailored  Black  Box  functions  poccess  tranaction 
closure? 

4)  Have  all  transition  possiblities  and  probabilities  been  changed  to  reflect  the 
expected  behavior  of  die  accumulation  of  increments? 

5)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data  § 

been  completed?  | 
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Task  S7.1  Consult  with  Development  and  Certification  Teams  About  Specification  Issues 

Task  S7.2  Update  Specifications  as  required 

Task  S7.3  Increase  Understanding  of  Problem  and  Solution  Domains 

Cycle  (i): _ Project: _  Team: _  Date: _ 


Y/N 

Completion  Condition  Question: 

1)  Have  tlr  results  of  all  investigations  of  problem  and  solution  domain  been 
properly  ruiected  in  specification  and/or  communicated  to  the  project  staff? 

2)  Have  all  submitted  issues  from  the  Development  and  Certification  teams 
about  the  specifications  been  considered?  H 

3)  Have  potential  changes  been  presented  to  the  various  teams?  g 

4)  Have  all  changes  to  the  specifications  been  validated  in  terms  of  consistency  I 
with  other  volumes  of  the  specifications?  1 

5)  Have  the  specifications  been  maintained  under  configuration  control?  1 

5a)  Have  all  major  issues  been  used  to  trigger  replanning  efforts?  1 

5b)  Have  small  changes,  corrections  and  clarifications  been  maintained  in 
documents? 

5c)  Have  base  line  documents  been  issued  as  required? 

6)  Have  all  appropriate  modifications  been  approved  by  the  Configuration 

Control  Board? 

7)  Have  changed  volumes  been  baselined  and  placed  in  project  state  data? 

8)  Have  all  changes  been  distributed  to  the  proper  stakeholders? 

9)  Do  the  updated  specifications  clearly  call  out  changed  portions,  new 
portions,  and  deleted  portions? 

10)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Task  S8.1  Prepare  ail  required  user  documentation 


Cycle  (i):_ 


Project:. 


Team: 


Date: 


Y/N 

Completion  Condition  Question:  1 

1)  Has  the  user  documentation  been  made  consistent  with  the  full  specification? 

2)  Have  the  conventions  for  user  documentation  been  followed? 

3)  Have  all  customer  requirements  been  satisfied? 

4)  Have  all  editors  and  reviewers  returned  their  comments?  Have  the  1 

comments  been  appropriately  reflected  in  the  documents?  1 

5)  Were  the  reviewers  selected  to  be  representative  of  the  user  population?  1 

6)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data  1 

been  completed?  | 
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Task  S8.2  Specification  team  prepare  final  project  releases  according  to  the  plan 
Cycle  (i): _ Project: _  Team: _  Date:. 

1)  Have  the  desired  conventions  for  the  final  releases  been  followed? 

2)  Has  the  consistency  between  the  final  releases  and  the  plan  been  confirmed? 

3)  Have  the  releases  been  validated  for  consistency  with  the  project  state  data? 

4)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 


Completion  Condition  Question: 


Y/N 
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Task  SC2.1  Increase  Understanding  of  Problem  and  Solution  Domains 
Task  SC2.2  Update  Specifications 
Task  SC2.3  Publish  Change  Sheets 

Cycle  (i): _ Project _  Team: _  Date:. 


Y  /  N  Completion  Condition  Question: 

1)  Have  the  results  of  all  investigations  of  problem  and  solution  domain  been 
properly  reflected  in  specification  and/or  communicated  to  the  project  staff? 

2)  Have  all  submitted  issues  from  the  Development  and  Certification  teams 
about  the  specifications  been  considered? 

3)  Have  potential  changes  been  presented  to  the  various  teams? 

4)  Have  all  changes  to  the  specifications  been  validated  in  terms  of  consistency 
with  other  volumes  of  the  specifications? 

5)  Have  the  specifications  been  maintained  under  configuration  control? 

5a)  Have  all  major  issues  been  used  to  trigger  replanning  efforts? 

5b)  Have  small  changes,  corrections  and  clarifications  been  maintained  in 
documents? 

5c)  Have  base  line  documents  been  issued  as  required? 

6)  Have  all  appropriate  modifications  been  approved  by  the  Configuration 
Control  Board? 

7)  Have  changed  volumes  been  baselined  and  placed  in  project  state  data? 

8)  Have  all  changes  been  distributed  to  the  proper  stakeholders? 

9)  Do  the  updated  specifications  clearly  call  out  changed  portions,  new 
portions,  and  deleted  portions? 

10)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Completion  Condition  Forms 
for 

Development  Team  Tasks 
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Task  D3.j.3.2.2a  Refine  and  Verify  Black  Box 

Increment  (j): _  Project _  Team: _  Date:. 


Y  /  N  Completion  Condition  Question: 

1)  Have  team  reviews  been  held  for  the  Black  Box? 

2)  Has  the  Black  Box  passed  its  final  review? 

3)  Have  all  project/installation  standards  for  BDL  been  adhered  to,  including: 

a)  Using  only  the  four  basic  structures 

b)  Following  language  syntax  conventions 

c)  Providing  function  commentary  where  needed? 

4)  Is  the  item  developed  consistent  with  the  software  development  plan? 

5)  Has  the  black  box  function  been  clearly  defined  in  terms  of  stimulus 
histories,  and  using  an  acceptable  format? 

6)  Has  the  black  box  function  been  verified  to  its  specification  (Note:  A 
higher  level  clear  box  is  a  lower  level  black  box’s  specification)? 

7)  Does  the  black  box  function  process  all  stimuli  values,  both  valid  and 
invalid? 

8)  Are  all  stimuli  and  responses  identified,  clearly  labeled  with  meaningful 
names,  and  fully  described? 

9)  Have  sufficient  black  box  analyses  been  performed?  Has  black  box  closure 
been  verified? 

10)  Are  the  black  box  verification  arguments  complete,  accurate,  and  clear? 

1 1)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Task  D5.j.3.2.2b  Refine  and  Verify  State  Box 

Increment  (j): _  Project _  Team: _  Date: _ 

Y  /  N  Completion  Condition  Question: 

1)  Have  team  reviews  been  held  for  the  State  Box? 

2)  Has  the  State  Box  passed  its  final  review? 

3)  Have  all  project/installation  standards  for  BDL  been  adhered  to,  including: 

a)  Using  only  the  four  basic  structures 

b)  Following  language  syntax  conventions 

c)  Providing  function  commentary  where  needed? 

4)  Has  the  state  box  been  verified  to  provide  equivalent  behavior  to  its  black 
box?  Are  the  state  box  verification  arguments  complete,  accurate,  and  clear? 

5)  Does  the  state:  box  function  process  all  stimuli  values,  both  valid  and 
invalid,  leaving  the  state  data  in  a  valid  state? 

6)  Have  trade  studies  been  conducted  for  all  state  data  decisions: 

a)  For  elaboration  at  the  selected  level  in  the  usage  hierarchy? 

b)  Does  state  data  abstraction  have  the  right  balance  between  execution 
speed,  performance  and  verifiability? 

7)  Has  transaction  closure  been  obtained  for  all  state  boxes? 

8)  Are  all  required  state  data  designed,  clearly  labeled  with  meaningful  names, 
and  fully  described? 

9)  Are  the  design  decisions  on  state  data  grouping  good  ones? 

10)  Have  all  state  box  behaviors  been  clearly  defined  in  terms  of  current 
stimulus  and  current  state? 

11)  Have  sufficient  state  box  analyses  been  performed?  Has  state  box  closure 
been  verified?  Has  a  state  usage  analysis  been  performed? 

14)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Task  D5.j.3.2.2c  Refine  and  Verify  Clear  Box 


Increment  (j):_ 


Project. 


Team: 


Date: 


Completion  Condition  Question: 

Y/N 

1)  Have  team  reviews  been  held  for  the  Gear  Box?  Has  the  Clear  Box  passed 
its  final  review? 

2)  Have  all  project/installation  standards  for  BDL  been  adhered  to,  including: 

a)  Using  only  the  four  basic  structures 

b)  Following  language  syntax  conventions 

c)  Providing  function  commentary  where  needed? 

3)  Has  the  state  box  been  verified  to  provide  equivalent  behavior  to  its  black  | 

box?  Are  the  state  box  verification  arguments  complete,  accurate,  and  clear? 

4)  Are  all  interfaces  in  the  usage  hierarchy  well  defined? 

5)  Has  transaction  closure  been  obtained  for  die  clear  box?  1 

6)  Are  all  procedural  constructs  in  the  clear  box  clearly  described?  1 

7)  Are  the  design  decisions  on  the  internal  black  boxes  good  ones?  Do  the  | 

internal  black  boxes  define  cohesive,  independent  behaviors?  Do  the  internal 
black  boxes  support  effective  state  migration?  I 

8)  Have  all  clear  box  behaviors  been  clearly  defined  in  terms  of  current 
stimulus  and  current  state? 

9)  Have  sufficient  clear  box  analyses  been  performed?  Has  clear  box  closure 
been  verified?  Is  referential  transparency  clearly  supported  in  the  clear  box? 

10)  Have  all  object  composition  opportunities  and  common  service  opportuni¬ 
ties  been  explored? 

11)  Has  the  use  of  concurrent  behaviors  in  the  clear  box  been  exploited?  If  so, 
are  appropriate  concurrency  controls  in  place? 

12)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Task  D5.j.3.2.2d  Refine  and  Verify  Clear  Box  Refinement 


Increment  (j):_ 


Project:. 


Team: 


Date: 


Y/N 

Completion  Condition  Question: 

1)  Have  team  reviews  been  held  for  the  Clear  Box? 

2)  Has  the  Clear  Box  passed  its  final  review? 

3)  Have  all  project/installation  standards  for  BDL  been  adhered  to,  including: 

a)  Using  only  the  four  basic  structures 

b)  Following  language  syntax  conventions 

c)  Providing  function  commentary  where  needed? 

4)  Is  the  item  developed  consistent  with  the  software  development  plan? 

5)  Has  the  Clear  box  function  been  validated  to  be  equivalent  to  its  parent  clear 
box  function? 

6)  Has  the  shift  to  the  implementation  language  been  just  a  translation? 

7)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed?  1 
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Task  D5.j.2.5  Increase  Understanding  of  Problem  and  Solution  Domains 


Increment  (j): _  Project: _  Team: _  Date: 


V/N 

Completion  Condition  Question: 

1)  1)  Have  the  results  of  all  investigations  of  problem  and  solution  domain 
been  properly  reflected  in  the  design  and/or  communicated  to  the  project  staff? 

6)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed?  | 

I 
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Task  D6.j.4  Correct  failure,  verify  correction  and  prepare  ECN 

Increment  (j): _  Project: _  Team: _  Date: 


Y/N 

Completion  Condition  Question:  I 

1)  Has  each  engineering  change  notice  been  completed  properly? 

2)  Have  all  chai.ges  been  reflected  through  out  the  design  hierarchy? 

3)  Have  all  changes  been  verified  and  passed  teams  reviews? 

4)  Have  all  engineering  change  notices  been  returned  to  the  certification  team? 

5)  Have  any  failures  remained  unresolved? 

1 

6)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Task  D8.3  Development  team  prepare  final  project  releases  according  to  the  plan 


Increment  (j):. 


Project:. 


Team: 


Date: 


I  Y/N 

Completion  Condition  Question: 

1)  Have  the  desired  conventions  for  the  final  releases  been  followed?  | 

2)  Has  the  consistency  between  the  final  releases  and  the  plan  been  confirmed?  | 

3)  Have  the  releases  been  validated  for  consistency  with  the  project  state  data? 

L 

4)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Completion  Condition  Forms 
for 

Certification  Team  Tasks 
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Task  C5.j.2.1  Prepare  Test  Plan 


Increment  (j):_ 


Project:. 


Team: 


Date: 


Y/N 

Completion  Condition  Question: 

1)  Does  the  test  plan  for  the  increment  account  for  all  strata  necessary  for 
certification? 

2)  Does  the  test  plan  for  the  increment  present  the  number  of  test  scenarios 
planned  to  certify  the  increment? 

3)  Does  the  test  plan  for  the  increment  present  the  stopping  criteria  for  the 
certification  effort? 

4)  Is  the  test  plan  consistent  with  the  usage  model?  I 

5)  Is  the  test  plan  consistent  with  resource  constraints?  R 

6)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data  | 

been  completed?  1 
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Task  C5.j.2.2  Prepare  test  scenarios  or  test  case  generator  for  accumulation  j 
Task  C5.j.2.3  Determine  expected  results  for  test  cases 

Increment  (j): _  Project: _  Team: _  Date: _ 

Y  /  N  Completion  Condition  Question: 

1)  Are  the  test  scenarios  consistent  with  the  test  plan  for  the  accumulation? 

2)  Are  the  test  scenarios  created  directly  from  the  usage  model  for  this 
accumulation? 

3)  Have  the  proper  number  of  test  scenarios  been  created  per  stratum? 

4)  Are  the  state  transitions  for  the  test  scenarios  randomly  generated? 

5)  Have  expected  results  been  created  for  each  test  scenario? 

6)  Have  expected  results  been  validated  in  regards  to  the  specification  for  the 
accumulation? 

7)  Have  expected  results  been  organized  with  their  respective  test  scenarios  in 
order  to  make  the  validation  effort  efficient? 

8)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Task  C5.j.3.4  Increase  Understanding  of  Problem  and  Solution  Domains 
Increment  (j): _  Project _  Team: _  Date:. 


Y/N 

Completion  Condition  Question:  I 

1)  Have  the  results  of  all  investigations  of  problem  and  solution  domain  been  | 
properly  reflected  in  specification  and/or  communicated  to  the  project  staff?  1 

2)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data  | 

been  completed?  1 
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Task  C6.j.l  Build  Accumulation  j 


Increment  (j): _  Project; _  Team: _  Date:. 


Y/N 

Completion  Condition  Question: 

1)  Have  all  components  in  the  increment  been  registered  into  the  library/placed 
under  configuration  control? 

2)  Has  an  attempt  to  compile  and/or  link/assemble  all  components  been  made? 

3)  Is  the  status  of  the  executable  system  documented? 

4)  Is  the  accumulation  consistent  with  the  Construction  Plan? 

1 

. 

5)  Do  all  changes  have  a  corresponding  Engineering  Change  Notice? 

6)  Has  the  necessary  version  information  been  collected  for  certification? 

7)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Task  C6.j.2  Perform  Certification  Tests  for  Accumulation  j 
Increment  (j): _  Project _  Team: _  Date: 

1)  Have  the  suite  of  test  cases  been  run? 

2)  Have  all  expected  results  been  compared  to  actual  results? 

3)  Has  appropriate  data  for  reliability  estimation  been  captured? 

4)  Have  all  failure  reports  been  submitted? 

3)  Have  all  failures  been  resolved  by  engineering  change  notices? 

6)  Have  the  certification  team  attempted  to  achieve  the  certification  goals 
specified  in  the  Test  Plan? 

7)  Have  all  test  scenarios  executed  been  included  in  the  testing  log? 

7)  Do  all  changes  have  a  corresponding  Engineering  Change  Notice? 

8)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 


Completion  Condition  Question: 


Y/N 
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Task  C6.j.3  Prepare  failure  report(s) 


Increment  (j): _  Project: _  Team: _  Date: 


Y/N 

Completion  Condition  Question: 

1)  Has  each  failure  report  been  completed  properly? 

2)  Have  all  failure  reports  been  submitted? 

3)  Have  all  failures  been  resolved  by  engineering  change  notices? 

4)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Task  C6.j.6  Prepare  Certification  Report 

Increment  (j): _  Project: _  Team: _  Date: 


Y/N 

Completion  Condition  Question: 

1)  Have  ail  test  executions  been  noted  in  the  report? 

2)  Have  all  observed  failures  been  noted  in  the  report? 

3)  Have  actual  reliability  estimates  been  made  and  compared  to  the 
expectations? 

4)  Has  certification  of  the  software  been  frozen  until  failures  are  resolved? 

S)  Has  the  current  status  of  certification,  in  terms  of  tests  run,  and  those 
remaining  to  be  run,  been  presented  in  the  report? 

6)  Has  the  report  been  submitted  to  all  necessary  stakeholders? 

7)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Task  C8.4  Certification  team  prepare  final  project  releases  according  to  the  plan 
Increment  (j): _  Project: _  Team: _  Date: 


Y/N 

Completion  Condition  Question: 

1)  Have  the  desired  conventions  for  the  final  releases  been  followed? 

2)  Has  the  consistency  between  the  final  releases  and  the  plan  been  confirmed? 

3)  Have  the  releases  been  validated  for  consistency  with  the  project  state  data? 

4)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Completion  Condition  Forms 
for 

Selected  Management  Tasks 
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Task  Ml. 4  Tailor  software  development  plan  for  project/spiral 


Project:. 


Manager:. 


Date: 


Y/N 

Completion  Condition  Question: 

1)  Is  the  software  development  plan  complete? 

2)  Was  the  Software  Development  Plan  reviewed  by  its  entire  set  of 
stakeholders? 

3)  Did  the  Software  Development  Plan  pass  its  final  review? 

4)  Does  the  Software  Development  Plan  follow  the  format  described  in  Volume 

2  of  the  Engineering  Handbooks? 

5)  Has  the  Software  Development  Plan  been  archived  in  its  proper  place  in  the 
project  state  data? 

6)  Have  all  questions  or  issues  submitted  while  developing  the  Software 
Development  Plan  been  resolved  sufficiently  to  allow  completion  of  the 

Software  Development  Plan? 

7)  Has  the  consistency  between  the  Software  Development  Plan  and  the 

Business  Plan  been  validated? 

8)  Is  the  software  development  plan  consistent  with  the  plan  for  the 
project/spiral? 

9)  Is  the  plan  for  the  project/spiral  complete? 

4)  Have  skill  development  resources  for  the  project/spiral  been  acquired? 

10)  Has  the  project  state  data  repository  been  created? 

11)  Has  the  process  management  system  been  made  available? 

12)  Have  all  necessary  metrics  been  gathered  in  the  creation  of  the  Software 
Development  Plan? 

13)  Have  engineering  tools  been  acquired  for  the  software  engineers? 
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14)  Has  the  engineering  process  for  the  project  been  defined? 

15)  Have  engineering  handbooks  for  the  project  been  made  available? 

16)  Have  communications  protocols  been  organized  for  the  project/spiral? 

17)  Have  the  manual  enactment  mechanisms  for  the  project  been  completed? 

18)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Task  Ml.S  Initialize  metrics  collection  activities 


Project: _  Manager: _  Date: 


Y/N 

Completion  Condition  Question: 

1)  Do  the  metrics  defined  fulfill  the  requirements  for  proper  Quality, 

Productivity  and  Cycle  Time  measurements? 

2)  Are  the  metrics  defined  consistent  with  the  process  improvement  plan? 

3)  Has  the  determination  been  made  between  which  measures  will  be 
automatically  gathered  and  which  will  be  manually  gathered? 

4)  Are  the  support  measures  in  place  for  automatic  metrics  gathering?  j 

5)  Have  the  mechanisms  for  manually  gathering  metrics  been  defined  in  the  1 

SDP?  | 

6)  Does  the  metrics  suite  cover  the  full  set  of  Cleanroom  metrics  to  be 
gathered  for  the  project? 

_ 

7)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Task  M3.1.k.l  Prepare  Review 
Task  M3.1.k.2  Conduct  Review 

Task  M3.1.k.3  Issue  Directives  to  Implement  Review  Findings 


Review: _ Project: _ Manager: _  Date: 


Y  '  N 

Completion  Condition  Question: 

1)  Has  state  data  been  available  for  review  preparation? 

2)  Has  all  state  data  been  made  available  for  reviewers? 

3)  Has  all  special  review  material  been  prepared  consistent  with  specifed 
requirements? 

4)  Has  review  material  be<*n  distributed  to  the  review  participants  in  a  timely 
manner? 

5)  Have  all  directives  based  on  the  review  been  distributed  to  the  proper 
personnel? 

6)  Are  directives  consistent  with  the  current  plan? 

7)  Has  the  responsibility  to  ensure  that  directives  are  completed  been 
delegated? 

8)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data  | 

been  completed?  H 
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Task  M4.i.l.l  Establish  Objectives  For  Cycle  i 
Task  M4.L1.2  Allocate  Time  Period  To  Cycle  i 
Task  M4.i.l.3  Prepare  Plan  For  Cycle  i 

Cycle: _  Project: _  Manager: _  Date: 


Y/N 

Completion  Condition  Question:  | 

1)  Are  the  objectives  for  the  cycle  clearly  described?  1 

2)  Are  the  objectives  consistent  with  previous  cycles?  1 

3)  Are  the  objectives  consistent  with  what  has  been  learned  on  previous  cycles?  B 

4)  Is  the  time  period  determined  for  the  cycle  consistent  with  the  schedule?  | 

5)  Is  the  plan  consistent  with  the  time  period? 

6)  Is  the  plan  consistent  with  the  objectives? 

7)  Does  the  plan  use  the  resources  allocated  for  the  specification  cycle? 

8)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 

ID52  -  Vol.  3  -  Project  Execution  in  Cleanroom 


Page  65 


Task  M4.i.5.1  Review  and  Evaluate  Cycle  i  Specifications 


Cycle:. 


Project:. 


Manager:. 


Date: 


I  Y/N 

Completion  Condition  Question: 

1)  Did  all  appropriate  staff  and  outside  experts  participate  in  the  review? 

2)  In  the  review  and  analysis  were  the  following  factors  considered? 

2a)  risk  mitigation? 

2b)  cycle  objectives? 

2c)  identification  of  what  was  learned? 

2d)  is  the  behavior  heading  in  the  right  direction?  1 

2e)  what  else  needs  to  be  learned?  1 

2f)  incremental  delivery? 

1 _ 

3)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 
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Task  MCS1.1  Appraise  Situation  and  Plan  Investigation 
Task  MCS1.2  Conduct  Investigation 
Task  MCS1.3  Analyze  results 

Task  MCS1.4  Revise  Software  Development  Plan  in  Accordance  with  Decision 


Replan  No: _  Project: _  Manager: _  Date: 


Y/N 

Completion  Condition  Question:  | 

1)  Has  the  problem(s)  that  caused  the  review  been  clearly  identified  and  1 

defined?  | 

2)  Has  the  plan  for  the  investigation  been  documented?  Is  the  staff  available?  | 

3)  Have  all  results  from  analysis  been  documented?  1 

4)  Has  the  investigation  decision  been  made?  | 

5)  Has  the  investigation  decision  been  justified? 

6)  Has  the  investigation  decision  been  documented? 

7)  Has  the  SDP  been  revised? 

8)  Have  the  completion  conditions  been  completed  for  the  revised  SDP? 

9)  Have  all  necessary  stakeholders  been  apprised  of  the  results  of  the 
investigation? 

10)  Have  all  process  status  corrections  (designing  tasks,  etc.)  been  made 
consistent  with  the  revisions  to  be  made  in  the  Software  Development  Plan? 

11)  Have  all  additions  to,  deletions  of,  and  modifications  of  project  state  data 
been  completed? 

% 
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Cleanroom  Engineering  Project  Execution 

Section  5:  File  and  Tool  Reference  Table 

Tables  that  summarize  the  files  necessary  to  perform  each  task  have  been  prepared. 

The  tables  also  list  available  tools.  This  information  is  preliminary  so  these  tables  will  be 
updated  from  lessons  learned.  There  is  one  table  for  each  team  and  a  fourth  table  for  selected 
management  tasks. 
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Tool  and  File  List  For  Specification  Team  Tasks 


ts 
c r> 


ID52  -  Vol.  3  -  Project  Execution  in  Cleanroom  Page  69 


ID52  -  Vol.  3  -  Project  Execution  in  Cleanroom  Page  70 


1 


ID52  -  Vol.  3  -  Project  Execution  in  Cleanroom  Page  71 


Tool  and  File  List  For  Development  Team  Tasks 
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Tool  and  File  List  For  Selected  Management  Tasks 
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Cleanroom  Engineering  Project  Execution 
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Process  Control  Documents  for 

Project  &project  Spiral  &spiral  Date  July  7,  1993 
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Project  &project  Spiral  &spiral  Date  July  7,  1993  (New/Changed/Unchanged)  (Active/Inactive/Complete) 


stakeholders] 

run  P8:  Product  (Project)  Releases; 


Project  Aproject  Spiral  Aspiral  Date  July  7,  1993  (New/Changed/Unchanged)  (Active/Inacdve/Complete) 
Responsible  o  Invoked  On  o  Due  On  o  Effort:  Plan  <>  ToDate  o  ETC  o  Focus  o 


Project  &project  Spiral  &spiral  Date  July  7,  1993  (New/Changed/Unchanged)  (Active/Inactive/Coinplete) 


Project  &project  Spiral  &spiral  Date  July  7,  1993  (New/Changed/Unchanged)  (Active/Inactive/Complete) 


Project  Aproject  Spiral  &  spiral  Date  July  7,  1993  (New/Changed/Unchanged)  (Active/Inactive/Complete) 
Responsible  o  Invoked  On  o  Due  On  o  Effort:  Plan  o  ToDate  o  ETC  o  Focus  o 


Completion  Conditions  for  all  initiated  processes  are  achieved 


Project  &project  Spiral  &spiral  Date  July  7,  1993  (New/Changed/Unchar  ted)  (Active/Inactive/Complete) 


corp; 


Project  Aproject  Spiral  &  spiral  Date  July  7,  1993  (New/Changed/Unchanged)  (Active/Inactive/Complete) 


Specification  Cycle  Tracking  Form  Project  &project  Date  July  7,  1993 


Project  &project  Spiral  &  spiral  Date  July  7,  1993  (New/Changedl/Unchanged)  (Active/Inactive/Complete) 
Cycle  o 


Project  &project  Spiral  &spiral  Date  July  7,  1993  (New/Changed/Unchanged)  (Active/Inactive/Complete) 


sufficient  completion  conditions  achieved  for  all  selected  analysis  methods  and  (time 
period  up  or  sufficient  understanding  has  been  obtained) 


sufficient  completion  conditions  achieved  for  all  selected  analysis  methods  and  (time 
period  up  or  sufficient  understanding  has  been  obtained) 


Project  &project  Spiral  &  spiral  Date  July  7,  1993  (New/Changed/(Jnchanged)  (Active/Inactive/Coniplete) 
Cycle  o 


Project  &project  Spiral  &spiral  Date  July  7,  1993  (New/Changed/Unchanged)  (Active/Inactive/Complete) 


Project  ^project  Spiral  Aspiral  Date  July  7,  1993  (New/Changed/Unchanged)  (Active/Inac ti ve/Complete) 


Project  Aproject  Spiral  &  spiral  Date  July  7,  1993  (New/Changed/Unchanged)  (Active/Inactive/Complete) 


Project  Aproject  Spiral  &  spiral  Date  July  7, 1993  (New/Change4/Unchanged)  (Active/Inactive/Complete) 


Project  Aproject  Spiral  Aspiral  Dale  July  7,  1993  (New/Changed/Unchanged)  (Active/Inactive/Complete) 
Increment  o  Box  o  Refinement  o 


Box  Refinement  Tracking  Form  Project  &project  Date  July  7,  1993 


Project  &project  Spiral  &  spiral  Date  July  7,  1993  (New/Changed/Unchanged)  (Active/Inactive/Complete) 


corp; 


Project  &project  Spiral  &  spiral  Date  July  7,  1993  (New/Changedl/Unchanged)  (Active/Inactive/Complete) 


Project  &project  Spiral  &spiral  Date  July  7,  1993  (New/Changed/Unchanged)  (Active/Inactive/Complete) 


Project  Aproject  Spiral  Aspiral  Date  July  7,  1993  (New/Changed/Unchanged)  (Active/Inactive/Complete) 


